apps/apollo-vertex/app/api/jira/route.ts:8

• No code in apps/apollo-vertex appears to call /api/jira (searching for /api/jira returns no matches), and the Roadmap Status page fetches Jira directly via fetchJiraIssues(). If this endpoint isn’t needed for external consumers, removing it would reduce public attack surface and maintenance burden; otherwise, consider wiring the page to use it so there’s a single data path to maintain.

// Intentionally public — this endpoint surfaces cross-team design system status.
// No auth guard is by design; confirmed with @ruudandriessen.
export async function GET(_req: NextRequest) {
  try {

apps/apollo-vertex/lib/jira-resolve.ts:166

• The “Component:” convention only uses the first whitespace-delimited token (e.g., "Alert Dialog" becomes "alert"), which prevents slug resolution for multi-word components like alert-dialog and button-group. Consider slugifying the full component name (optionally trimming any trailing "(…)" or ", …" qualifiers) before looking up the path.

  const componentMatch = descText.match(/^Component:\s*(.+)$/im);
  if (componentMatch) {
    const rawSlug = componentMatch[1].match(/^([^\s(,]+)/)?.[1];
    if (rawSlug) {
      const slug = rawSlug

apps/apollo-vertex/lib/jira.ts:56

• JIRA_BASE_URL may be configured with a trailing slash (e.g., https://…/), which would generate a double-slash in the request URL (//rest/api/...). Normalizing the base URL avoids subtle request/redirect issues.

  const base = process.env.JIRA_BASE_URL;

apps/apollo-vertex/lib/jira.ts:63

• The missing-config error message tells people to add vars to .env.local, but the UI error state points to apps/apollo-vertex/.env.local. Aligning the message avoids confusion when setting this up locally.

    throw new Error(
      "Missing Jira configuration. Add JIRA_BASE_URL, JIRA_EMAIL, and JIRA_API_TOKEN to .env.local",
    );

apps/apollo-vertex/lib/jira.ts:92

• Throwing the full Jira error response body can leak unnecessary details to downstream callers (and can be very large if Jira returns HTML). Prefer using the status + statusText (and optionally logging the full body server-side) instead of embedding the entire body in the thrown message.

    if (!res.ok) {
      const text = await res.text();
      throw new Error(`Jira API error ${res.status}: ${text}`);
    }

apps/apollo-vertex/app/api/jira/route.ts:19

• This route is marked intentionally public and calls Jira using server-side credentials. Two concerns: (1) Cache-Control: no-store means every request triggers a Jira API call, which is vulnerable to accidental/intentional traffic spikes and Jira rate limits; (2) returning the raw exception message can leak internal details. Consider adding CDN caching and only returning a safe error message (still preserving the missing-config hint if you want).

      headers: { "Cache-Control": "no-store" },
    });
  } catch (e) {
    const message = e instanceof Error ? e.message : String(e);
    return NextResponse.json({ error: message }, { status: 500 });

apps/apollo-vertex/lib/jira.ts:94

• The error thrown on non-2xx Jira responses includes the full response body (await res.text()). This can leak unexpected internal details to the UI/API consumer and can also create extremely large error messages if Jira returns HTML or verbose JSON. Consider only including the status code in production, optionally appending the body only in non-production for debugging.

    if (!res.ok) {
      // eslint-disable-next-line no-await-in-loop -- cursor pagination is inherently sequential
      const text = await res.text();
      throw new Error(`Jira API error ${res.status}: ${text}`);
    }

apps/apollo-vertex/app/api/jira/route.ts:19

• This public API route returns the raw caught error message to clients. In production that can inadvertently expose internal details (for example, upstream HTML/JSON error bodies) and makes the endpoint easier to probe. Consider returning a generic message in production (while still preserving the "Missing Jira configuration" setup hint).

  } catch (e) {
    const message = e instanceof Error ? e.message : String(e);
    return NextResponse.json({ error: message }, { status: 500 });
  }

apps/apollo-vertex/lib/jira-resolve.ts:215

• sortComingSoon only distinguishes review vs non-review and otherwise returns 0, which relies on the JS engine's sort stability to preserve the incoming (JQL) ordering. Adding an explicit tie-breaker (for example updated descending) avoids potentially non-deterministic ordering and keeps the "most recently updated" items at the top within each group.

function sortComingSoon(cards: ProcessedCard[]): ProcessedCard[] {
  return [...cards].sort((a, b) => {
    const aReview = isReviewStatus(a.status);
    const bReview = isReviewStatus(b.status);
    if (aReview !== bReview) return aReview ? -1 : 1;
    return 0;
  });
}

apps/apollo-vertex/app/api/jira/route.ts:15

• This route is public and triggers live Jira fetches, but there are no in-repo references to /api/jira (it isn’t used by the new StatusBoard either). If it’s not intended for external consumers, consider removing it to reduce public surface area and Jira load, or switch the UI to consume this endpoint so it has a single fetch path.

// Intentionally public — this endpoint surfaces cross-team design system status.
// No auth guard is by design; confirmed with @ruudandriessen.
export async function GET(_req: NextRequest) {
  try {
    const issues = await fetchJiraIssues();
    const jiraBaseUrl =
      process.env.JIRA_BASE_URL ?? "https://uipath.atlassian.net";
    const data = processIssues(issues, jiraBaseUrl);
    return NextResponse.json(data, {
      headers: { "Cache-Control": "no-store" },
    });

apps/apollo-vertex/lib/jira.ts:64

• JIRA_BASE_URL is used as-is. If it’s configured with a trailing slash (common in env files), requests will go to ...//rest/api/.... Also, the thrown setup error points to .env.local while the UI error state points to apps/apollo-vertex/.env.local, which is inconsistent for users.

  const base = process.env.JIRA_BASE_URL;
  const email = process.env.JIRA_EMAIL;
  const token = process.env.JIRA_API_TOKEN;

  if (!base || !email || !token) {
    throw new Error(
      "Missing Jira configuration. Add JIRA_BASE_URL, JIRA_EMAIL, and JIRA_API_TOKEN to .env.local",
    );

apps/apollo-vertex/lib/jira-resolve.ts:175

• Component: convention parsing only keeps the first token before whitespace, so values like Component: Alert Dialog or Component: Button Group will slugify to alert/button and fail to resolve to alert-dialog/button-group. This breaks the intended convention lookup for multi-word component names.

  const componentMatch = descText.match(/^Component:\s*(.+)$/im);
  if (componentMatch) {
    const rawSlug = componentMatch[1].match(/^([^\s(,]+)/)?.[1];
    if (rawSlug) {
      const slug = rawSlug
        .toLowerCase()
        .replace(/[^a-z0-9]+/g, "-")
        .replace(/(^-|-$)/g, "");
      const path = SLUG_PATH_MAP.get(slug);
      if (path) return { url: path, source: "convention" };
    }

apps/apollo-vertex/lib/jira.ts:88

• cache: "no-store" forces every page view (and every call to the public API route) to hit Jira directly, which can become a reliability/rate-limit issue. Consider using a short server cache via Next’s fetch revalidation (for example 60s) so the page is still near-real-time but resilient to spikes.

        Accept: "application/json",
      },
      body: JSON.stringify(body),
      cache: "no-store",
    });

apps/apollo-vertex/app/api/jira/route.ts:19

• This route returns the raw caught error message to unauthenticated callers. Even with improved upstream errors, it’s better to avoid exposing internal failure details on a public endpoint. Also, Cache-Control: no-store means every request will hit Jira, increasing the risk of rate limiting/abuse for a public URL.

    return NextResponse.json(data, {
      headers: { "Cache-Control": "no-store" },
    });
  } catch (e) {
    const message = e instanceof Error ? e.message : String(e);
    return NextResponse.json({ error: message }, { status: 500 });
  }

apps/apollo-vertex/lib/jira.ts:94

• Throwing Jira API error ...: ${text} includes the full upstream response body. That error string is later returned to clients (API route) and rendered in the UI (StatusBoard), which can leak internal details and produce very large error payloads. Prefer extracting a short, structured message (or truncating) instead of embedding the full body.

    if (!res.ok) {
      // eslint-disable-next-line no-await-in-loop -- cursor pagination is inherently sequential
      const text = await res.text();
      throw new Error(`Jira API error ${res.status}: ${text}`);
    }

apps/apollo-vertex/lib/jira-resolve.ts:161

• The Vertex: URL regex will include trailing punctuation (e.g. a period at end of sentence) because the character class allows . and ,. That can lead to broken external links for delivered cards.

  const vertexMatch = descText.match(
    /Vertex(?:\s+URL)?:\s*(https?:\/\/[^\s\n)]+)/i,
  );
  if (vertexMatch) {
    return { url: vertexMatch[1].trim(), source: "explicit" };
  }

apps/apollo-vertex/lib/jira-resolve.ts:175

• Component: convention slug parsing only takes the first whitespace-delimited token (Button from Button Group), which prevents resolving multi-word slugs like button-group and will incorrectly fall back to Jira for those delivered tickets. Slugify the full component value instead of truncating it.

  const componentMatch = descText.match(/^Component:\s*(.+)$/im);
  if (componentMatch) {
    const rawSlug = componentMatch[1].match(/^([^\s(,]+)/)?.[1];
    if (rawSlug) {
      const slug = rawSlug

apps/apollo-vertex/app/design-system-status/_components/status-board.tsx:178

• The non-config error state renders the raw error string from Jira/network failures. Since this page is publicly accessible, that can expose internal details (and can be very long if it includes upstream response bodies). Consider showing a generic message to users and keeping the detailed error server-side (logs) or only in development.

      ) : (
        <p className="text-sm text-muted-foreground">{message}</p>
      )}

apps/apollo-vertex/lib/jira-resolve.ts:224

• The comparator returns 0 for most pairs, which relies on the engine’s sort stability to preserve the existing Jira ordering. Stability is not guaranteed across all JS engines/spec interpretations, so the relative order of non-review items can change unexpectedly. Add a deterministic tie-breaker (e.g., compare updated descending, then key) or decorate with original indices.

function sortComingSoon(cards: ProcessedCard[]): ProcessedCard[] {
  return cards.toSorted((a, b) => {
    const aReview = isReviewStatus(a.status);
    const bReview = isReviewStatus(b.status);
    if (aReview !== bReview) return aReview ? -1 : 1;
    return 0;
  });
}

apps/apollo-vertex/lib/jira.ts:95

• Logging the full Jira error response body can leak sensitive information into server logs (Jira sometimes echoes request context or includes content). Consider truncating/redacting the body and/or only logging verbose bodies in non-production environments; at minimum log status + a request identifier rather than the full payload.

    if (!res.ok) {
      // eslint-disable-next-line no-await-in-loop -- cursor pagination is inherently sequential
      const body = await res.text();
      console.error(`Jira API error body (${res.status}):`, body);
      throw new Error(`Jira API error: ${res.status} ${res.statusText}`);
    }

apps/apollo-vertex/app/design-system-status/_components/status-board.tsx:143

• The UI branches on a substring match of an error message, which tightly couples rendering logic to exact punctuation/wording from the throw site. Prefer throwing a typed error (custom Error subclass) or including a structured error code so the UI can reliably detect missing configuration without parsing strings.

function SetupError({ message }: { message: string }) {
  const isMissingConfig = message.includes("Missing Jira configuration");

apps/apollo-vertex/lib/jira.ts:64

• The thrown error directs users to add variables to .env.local, while the UI error state in StatusBoard instructs apps/apollo-vertex/.env.local. Align these messages (same path and wording) to avoid confusing setup instructions.

  if (!base || !email || !token) {
    throw new Error(
      "Missing Jira configuration. Add JIRA_BASE_URL, JIRA_EMAIL, and JIRA_API_TOKEN to .env.local",
    );
  }

apps/apollo-vertex/lib/jira-resolve.ts:5

• This slug list is large and manually inlined, which is likely to drift from the actual site routes over time (despite the comment saying it’s derived from _meta.ts). To reduce drift, consider generating this map from the source-of-truth route metadata at build time (or exporting/importing a shared constant), or add a validation step/test that asserts the list matches the real _meta.ts entries.

// All known routable slugs per section, derived from the site's _meta.ts files
const SLUGS_BY_SECTION: Record<string, string[]> = {
  components: [

apps/apollo-vertex/lib/jira-resolve.ts:224

• Array.prototype.toSorted is not available in older Node runtimes (notably Node 18). If this app targets or may run on Node 18 (common for many Next deployments), this will crash at runtime. Consider using cards.slice().sort(...) (or a small helper) for broader compatibility.

function sortComingSoon(cards: ProcessedCard[]): ProcessedCard[] {
  return cards.toSorted((a, b) => {
    const aReview = isReviewStatus(a.status);
    const bReview = isReviewStatus(b.status);
    if (aReview !== bReview) return aReview ? -1 : 1;
    return 0;
  });
}

apps/apollo-vertex/app/api/jira/route.ts:21

• This endpoint is intentionally public, but returning raw exception messages can leak internal configuration details (e.g., env var names/paths) and upstream error information. Prefer logging the detailed error server-side and returning a generic client-facing message (optionally with a stable error code) to avoid information disclosure.

  } catch (e) {
    const message = e instanceof Error ? e.message : String(e);
    return NextResponse.json({ error: message }, { status: 500 });
  }

apps/apollo-vertex/app/design-system-status/_components/status-board.tsx:143

• This UI branches on a substring match of the error message, which is brittle (any wording change breaks the detection). A more robust approach is to throw a dedicated error type or attach a stable code (e.g., JIRA_CONFIG_MISSING) and branch on that instead of parsing message.

function SetupError({ message }: { message: string }) {
  const isMissingConfig = message.includes("Missing Jira configuration");